Slashdot Mirror
The Poetry Of Programming
Lumpish Scholar writes "Sun's Richard Gabriel (possibly the only person with both a Ph.D. in computer science and an MFA in poetry) talks about "the connections between creativity, software, and poetry": "People say, 'Well, how come we can't build software the way we build bridges?' The answer is that we've been building bridges for thousands of years, and while we can make incremental improvements to bridges, the fact is that every bridge is like some other bridge that's been built.... But in software ... we're rolling out -- if not the first -- at most the seventh or eighth version. We've only been building software for 50 years, and almost every time we're creating something new.""
Defy physics between two points. Software changes because what we do with it can change.
Process swiftly crash NULL pointers everywhere O -- Electric Fence!
Roving Web-Teleoperated Robot
Whenever I create software, it takes a lot out of me. Much like Picasso's painting, Michaelangelo's Sistene Chapel, ee cummings literary works (only I use more punctuation marks than she does), I am an artist. My work is meaningful and beautiful, and a part of me, which is why I release it under the GPL. For the GPL, itself, is also a work of art. It brings light to the darkness, it brings joy to the huddled masses of ones and seros yearning to be free.
Would it make it to the next century?
Would bring a whole new meaning to the term 'Blue Screen of DEATH' crashandburn99
Why did you feel the need to share that?
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
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.
Are we really creating something new each time, or creating things in parallel? I'm not an advanced programmer by any means but I've taken a few classes and noticed that the typical approach is to have students recreate solutions to common problems for the purposes of learning (e.g. The Towers of Hanoi to learn recursion), are we enculturating ourselves to go it alone rather than look at what others have done before us?
Try building a bridge:
a) with half the crew and materials required
b) in a quarter of the required time
c) that will be retrofitted to support train tracks and a second level
d) that will be backwards compatible with the previous bridge
e) that is better than your competitors bridge
Jason.
Using ISO9000 (define what to do, do it and document it), proper object orientation software is (should) built like bridges.
Any major software company not reusing components and controlling the design/implementation process will fail. The reuse of components not only benefits the developers, but also the users (just look at KDE or Adobe's software, dialogs and tools are easily reused).
The reuse of software requires direction, thought and documentation. You must know what it is that you try to do, break it down into sections (objects) and define the interfaces and interactions before you sit down and write any code. This is the most common mistake when coding and the biggest problem in open source projects that begin as small personal pets of the project initiator and quickly grows out of hand.
As I look over this beautiful land
I can't help but realize
That I am alone
Why am I able to waste my energy
To notice life being so beautiful?
Maybe partying will help.
D. Boon
I bet this guy owns that "Code Poet" shirt from Think Geek.
This message brought to you by the Council of People Who Are Sick of Seeing More People.
The answer is that we've been building bridges for thousands of years, and while we can make incremental improvements to bridges, the fact is that every bridge is like some other bridge that's been built.... But in software ... we're rolling out -- if not the first -- at most the seventh or eighth version.
I hear this theory every now and then, and it's just dead wrong. The fundamental problem is that a program is thousands of times more complex than a bridge. Imagine constructing a bridge out of hundreds of thousands, if not millions, of custom-fabricated tiny parts that have to fit together exactly right or the whole thing collapses. That's the correct analogy.
When you also combine that with the fact that you can look at the totality of a bridge and get a "sense" of whether it's done right or not, at best you can only look at a few hundred lines of code at a time.
Sometimes it's best to just let stupid people be stupid.
The TRUE code poet... Someone needs to get this guy the Code Poet T-Shirt from thinkgeek!
http://www.thinkgeek.com/tshirts/coder/27ac/
People say, 'Well, how come we can't build software the way we build bridges?'
Because they're not analogous. Bridges are designed to be used for decades, if not centuries, by hundreds and thousands of people and vehicles without anything more than routine maintenance. The closest equivalent in the technology industry would be the mainframe computer.
"Ordinary" software, the kind meant to be used by consumers on their current PC which will be constantly upgraded, routinely unsecured and replaced within five years at best, is more like a gravel-top driveway with grass growing underneath.
sPh
It's quite obvious actually!
i agree, we are still very young in the computing yet alone programming age. Every program we write bringns something new; whether it be something more efficient, code reuse, or learning a new aspect of a language.
With the recent trends of OOD,OOP... one day we will be able to write code the way people build bridges. Even then we will still find ways to overcome current designs and code.
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.
I wear this tie
just so I can loosen it,
and look disheveled.
That's the game I play,
begging for a promotion,
a brown nose fashion.
I don't do this for the money --
really, I've got nothing to
do with it,
except buy more things
I'm unable to use,
or a nicer car to stow them in
while I fret over broken automatons,
robots that are mine to control.
I'm no diety, no ambassador,
no megalomaniac but a mechanic,
longing to chat idly with a machine
that know my voice,
needs me to operate
and performs better while I'm around,
trying to impress me.
Many years ago I may have been
a miller or a blacksmith,
6 days sweating day until night,
whistling through my ears as the mind
concentrates on placing the hammer,
following the gears and
sparking iron,
never thinking a boorish thought.
Ah, but instead to mill the data!
To forge queries and horde passwords!
It's not the dream of a child,
eyeing the romance of placing ones self in mortal danger,
but it is more than a paycheck:
to be an archivist
and a tradesman.
Must post anon because this is really a piece of shit. -- M
I have both a Ph.D. in computer science and an MFA in poetry.
Ignore the "p2p is theft" trolls, they're just uninformed
Did he just compare Windows to FreeBSD to Linux?
:)
I never could understand art
-
ping -f 255.255.255.255 # if only
Almost anybody can do something new. Not necessarily something awesome and groundbreaking like the O(1) scheduler, but pretty much anybody with some skill can make their little contribution in the form of a Perl module for example.
I also like that in programming it's fairly easy to reinvent things. For example I'm pretty sure a few people reinvented bubble sort or linked lists while playing with a programming language without having read anything but the manual for that language. Gives you a nice feeling to find that you were able to come up with useful things on your own.
Obvious reasons. Those foolish cavemen (or whoever) that built the first bridges didn't patent the design and copyright the plans. Then hide the bridge in big black boxes so nobody could try design something similar.
They also didn't have to worry about the greedy land owners at either side of the river charging them huge amounts (or just refusing them) to get information on ground they needed to build the bridge ends on.
$DEITY bless the software industry!
You Are Being Lied To.
He then added, "The whole process seems to be very slow and only the engineers with the best memories seem to be able to roll these versions out in a reasonable amount of time. And first getting started in the morning... don't even go there. Also, look at our offices; the furniture looks cheap and it looks like it was set up for the lowest common denominator."
A joke at Java's expense... don't take me seriously, please.
======================================
Writers get in shape by pumping irony.
Microsoft
You can have it fast, accurate, or pretty. Pick any 2.
Msft would never actually build the bridge, but they'd happily sell, at competitive price, a set of blueprints for new, inproved Advanced BridgeXP w/ patented extensions to the open High Level Traffic Shaping protocol (sorry, MsHLTS only works with MSHighWay) for a hefty fee and a legal disclaimer ("these blueprints provided AS IS w/o warranty express or implied as to useability or safety..."), but the state and taxpayers would have to do the construction. If any defects in the blueprints are found and corrected the state and taxpayers are responsible for obtaining new blueprints and the costs of implementing any corrections, incl wages of fitters, welders, construction equipment rentals, etc. Licensee of MSBridgeXP accepts all legal responsibilities for the safety of users, and indemnifies MSft of any and all risks. MSBridgeXP is protected by US and International copywrite treaties, and any unlicensed use will be prosecuted to the fullest extent of the law.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
According to this page, it should probably be E.E. Cummings, caps and all.
Things are more like they are now than they ever were before.
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.
teaky teaky too.
If you're creating something new "almost every time", you are doing something terribly wrong.
It's called research.
Not all of us are writing IRC/AIM clients.
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...
In school I studied both computer science and fine arts, and I consider the two extremely different. The biggest, most obvious difference is that in programming, you have a very good sense of when you're done. If your specs (either from your client, or your programming assignment) are relatively clear, you can write your code and be more-or-less satisfied that you've met them. You can write automated regression tests if you want to really make sure. (These days I almost always write automated tests.)
...
... If everybody did programming the way artists do art, programming would be even more buggy and expensive, which doesn't do anything good for respect for the craft. The way to get more respect for programming is to figure out ways to make us all better programmers. Anything else is just a distraction.
But for art? Forget about it. I can't tell you how many hours I spent agonizing in front of a painting or sculpture or comic book page, wondering if it was finished, if it had enough marks or not
The two are very different. Not that one is necessarily better than the other, but they're very different.
I think comments like Gabriel's often stem for a desire to get more respect for programming. Gabriel probably compared the respect that artists get, vs. the respect that programmers get, and decided that the way to get more respect for programming is to try to convince everybody that's a sort of art.
His intentions are good, but you end up muddying the waters too much that way
Do domain names matter?
This 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
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.
Aah, it sounds like you've worked on a properly funded and staffed project!
(Lucky bastard.)
"So, the idea behind the MFA in software is that if we want to get good at writing software, we have to practice it, we have to have a critical literature, and we have to have a critical context. It looks like we may be able to start a program like that in the next year or so at a major university that I'm not free to name. It's probably going to be called a Master of Software Arts."
I want that title.
Prescriptive grammar:linguistics
I was the editor of my high school's literary magazine back in the day (I was always more of an English person than a math person), and my senior year I submitted a C++ Hello World as a poem to the magazine. Got a lot of strange looks but it got in.
I have built a bridge that works just fine. But now the people on the other side of the bridge have decided they want my bridge to interface with their new Microslick Bridge Interface. This interface seems to be built on the same standard as mine but on their side only 2 of the 3 lanes seems to work. The interface documentation clearly states there are three lanes but one seems to be closed.
After a brief call (with a fee) to the Bridge Support Line it turns out that most people did not use the third lane so that functionality was not implemented. Maybe in the next release of the Interface.
There also seems to be a mandatory toll on the other side of the bridge. Unfortunately the toll booth operators don't seem to speak the same language that everyone on this side of the bridge speaks. It's close but the noun and verb order seems to be reversed. Confusing but we can work around it.
After buying the Bridge Interface Development Kit it seems that this new way of talking to the toll booth operators is more efficient than the way everyone else has used the language before. Who knew.
It also seems that the MS has patented a means of allowing a car to move from point a to point b where a and b are separated by impassable obstacles. So now I must license the technology I am using to interface with the MBI.
I am glad bridge building is so easy.
Gabriel's written 1000 poems in the last two years, which is about 1000 poems more than you have.
[sarcasm]
I bet youse hasn't written a grammatically correct post in their life.
[/sarcasm]
I don't think building bridges is as easy as he makes it sound. Here's one example he should take a look at.
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.
Perl poetry
How not to plan 101.
How to ignore OOP 101.
rms, the early years.
Seriously tho, some good ideas mentioned.
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?
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.
The mathematics behind many clever algorithms is simply astounding to me. The beauty of recursion is something as natural and poetic as music to me.
But that's to me.
Also, for me, most abstract art and whatever they call those paintings that are just a big red circle, is garbage. I think it's a waste of paint and is only meaningful to the creator. But millions of people believe this type of painting is artistic, even poetic.
Until you get to professional levels, anyone can tell a lousy poem or an ugly painting. In professional levels, it becomes more subjective. Many people are employed as painters although they aren't good at making good art. $5 paintings sold at Sears have to be painted by someone. Similarly, there are a whole lot of mediocre programmers out there, employed as programmers in a low level job. Most programmers or even logical thinkers who aren't programmers can identify bad programming, just as most people who are even casually interested in art can tell when an unskilled and untrained hand has done the painting.
But when a programmer sees a great algorithm for the first time, whether in a textbook or on a napkin, there's a certain beauty to it, a certain mathematical/locical poetry to it. The artistic pleasure comes from realizing what the artist was thinking when the made the art, whether it's an ingeniously simple technique for a peer to peer system, or a woman both in the distance and in the foreground at the same time in a Salvador Dali painting.
$8.95/mo web hosting
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
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...
That's neither art nor science... That's industry... right ;-)?
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
> 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.
http://rareformnewmedia.com/
I hope this doesn't sound like a flame, but Richard mentions:
/. reader would recognize).
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
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.... ?
I'll have something intelligent to add one of these days...
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.
This sig has been temporarily disconnected or is no longer in service
Very well said. Nothing to add. Except, maybe: :)
MOD UP !
-- don't discount flying pigs until you have good air defense
I had a helluva time a little over a year ago getting the latest version of PVCS running on Solaris 2.7 (maybe 2.8?).
you don't know what I do or do not do, fscktard.
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 ?
- 12-2001.html for the rest ... slashdot's asinine lameness filter won't let me include it here. It concludes...
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). 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
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.
The Future of Human Evolution: Autonomy
Word.
As an English major who has just been paid for the completion of his first software project, I am enthusiastic about the possiblity of the two disciplines comingling.
When I first had to master the Villanelle and the sestina for a creative writing class back in the eighties, I found my mind stimulated in a way unlike any thought process I had used before. When I began learning python last year, the tickle was familiar.
Please don't be too quick to write off the similarities between the two crafts and especially entertain the possibility that observing fine code written by masters just might improve your own. The Master of Software Arts sounds like an acheivement to be proud of.
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 think there's no way to compare building a bridge and building a decent piece of software. Everybody has his own speciality. I remember in Holland we let an architect build a bridge. It's a beautifull design but they had to strengthen in on all sorts of places after the first storm in autumn. I wonder what things would have looked like if we had let a computer-programmer build the thing. I'm pretty sure I wouldn't have passed the bridge in that case ;-)
/(bb|[^b]{2})/
It starts like this:
#include std_beauty
#include std_hack
and in a couple of years I look at and ask, "What on Earth were you thinking?" After a few hours, I might understand what I was doing and am pleased, or feel stupid.
Very much like poetry, no?
Friends don't help friends install M$ junk.
1) quick and dirty - like a trashy novel
2) well thought out - like Shakespeare
there's no way to do it cheap, fast AND good. Pick two of the three and that's what you can do.
Plus, you always get what you pay for... cheap and good is really hard compared to cheap and fast.
sir_haxalot
stuff |
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.
me too!
a/s/l?
me too!
AOL loser.
You may remember this great C poem (hint here) from IOCCC. It compiles, produces topic related output, and even makes lint say some funny stuff about it.
Bad programming is hardly identifiable by almost every programmer. Consider one case of bad programming: an obscure timing-related bug in some multithreaded software which causes the system to die under load.
How many "rank and file" programmers (as you call them) could identify and fix a problem like that without any creative thought?
I would also take issue with your comment that "almost any programming task has been reworked umpteen times". Sure, the fundamentals have remained mostly unchanged (eg. what sorting algorithm do I use?). But every year brings different challenges, new communications protocols, faster hardware, different requirements, etc. Even accounting software has to change frequently to accommodate new tax rules and so on. How often does someone come up to the builder of a bridge and say "This now needs to support 1000 more pedestrians a minute. Oh, and each one needs to get to the other side in half the time"?
You seem to consider "programmers" to be a lower form of life to theoreticians and system architects. I would argue that programming is an equally creative task - assuming that you work somewhere which allows it to be.
Reminds me of an older sig I once used:
"Assembly language: The Haiku of Code Poetry"
One of my friends asserted that it was comparable only to Haiku in Japanese, since Assembly was just as unintelligible to him...
True science means that when you re-evaluate the evidence, you re-evaluate your faith.
This part I agree with. When I took my Software Project Management course, the two most useful aspects were listening to the war stories of this 60+ year old instructor with tons of experience and reading business case studies. Similar thing in my Software Quality Assurance and also OO Patterns classs. Seeing how software projects failed, and in some cases killed people really drives home the point that QA is not to be ignored and teaches how to (hopefully) avoid making the same mistakes they did. So I do believe that learning by seeing what others have done is a powerful tool.
But where his argument falls apart is in treating it like an art. Engineering is already considered a creative process, but it's a disciplined creative process. The problem with software, as earlier posters have said, isn't too much engineering; it's too little.
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.
Heck even roads aren't that easy.
:).
Lack of documentation? Well how do you think the civil engineers feel when they start digging up stuff and find power cables and water pipes where they weren't supposed to be? Then the project is delayed for everything to be rerouted.
Later you get a bunch of people squatting on the land refusing to move. Then a bunch of environmentalists start chaining themselves to trees. Then you get some people sending you subpar stuff - concrete mix etc. BTW the deathrate in the construction industry is probably higher than the software industry.
Some time back the newspapers here were running stories about the power company et all complaining about road builders digging up and breaking their stuff. The boss of a construction company called the respective industry bosses up privately and asked for accurate maps of where their stuff was. They couldn't provide them and so they had to shut up, and somehow the newspapers stopped running those stories
As for design variations, civil engineers often have to change designs due to political reasons - this after supposedly everything has been approved. People start saying hey you need to build a new intersection here for _free_. Then the politicians start saying hmm maybe if you don't do it we might give subsequent projects to other people.
I received a bachelors in computer science in 1993 and have heard of these so-called "Peer Reviews" or "Code Reviews." However, not once was I taught that in school. It would have been extremely beneficial if computer science graduates had the skills of the peer review in the same way that recent fine arts graduates (theoretically) have the skills of the critique process.
The two very different disciplines share some important characteristics. Students are taught techniques and are given the opportunity to hone their expressive skills. In fine arts, the emphasis is on the expressive skills--it's better to create a work of art that is very expressive even if the techniques are poor. Computer science, on the other hand, emphasizes technique over expression--it's better to make a program that works poorly rather than an elegant algorithm that doesn't compile.
Unfortunately the computer science student is treated like an engineer and their creative skills are not taught, but left to the student to develop on their own, and, in part through attrition, functionally creative programmers leave college. Admittedly, a fine arts student isn't taught the way to express their creative ideas, but rather, given the opportunity to hone their implicit skills for expressing those ideas. Even better, through learning the process of the critique, they are given the skills necessary to continue to learn to improve on their own.
--- Jason Olshefsky
Karma: Poser (mostly affected by adding this line long after everyone else did)
Some other stuff here and here
"If anyone needs me, I'm in the angry dome."
Truly epic software is written in iambic pentameter. Portable utilities are written in sonnet form. Quick-n-dirty kludges are written as limericks. Haiku is for batch files.
~REZ~ #43301. Who'd fake being me anyway?
I think Gabriel's programming workshop concept is more novel than the software-to-bridge comparison. Learning about historical programs, learning about the lives of programmers, and writing hundreds of programs in a mentored environment would be an interesting approach. This may sound strange, but a lot of it happens already. There is already quite a bit of celebrity for some language inventors and other visionaries in the industry.
Perhaps programming studios will be not so much like Renaissance art schools, but more like craft workshops such as Karl Faberge's, where different craftsmen had different responsibilities, but they all came together to create something wonderful. This is because of the mentoring aspect (oversight by more experienced craftsmen), and the fact that programmers often have to collaborate with other programmers (to say nothing of managers, testers, users, etc.).
Although much of the proposed programming MFA program may remain a novelty, I expect some of it may filter out into the more standard undergraduate curriculum over time.
Well, hey, I didn't spend all those years playing Dungeons and Dragons and not learn a little something about courage.
1) Most are just tinkering about. It's like all those projects in people's gardening shed. Tinkering is fairly affordable in IT. Freshmeat just happens to be a list of backyard projects, some backyards having space rockets or monorails, but most having benches, bird houses and so on.
2) In software world if people want the exact same "bridge", they just make or buy another copy. The IT world does duplications far better than the construction world.
3) Often people just don't want the exact same thing as everyone else. If you don't mind the exact same thing see 2). But in my experience many people and companies are different, want to be different etc. So even if everything goes open source, programmers etc will still have jobs. Plenty in fact.
> 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.
In an idea environment, I completely agree with you. This type of environment generally requires that the project manager and/or the systems analyst/architect has significant experience in technology. However, even in this idea environment, these "visionaries" will solicit opinions and suggestions from the most experienced programmers (brick-layers).
What I have found in many old businesses is that the management style has not changed at all in recent times. In many cases, the management has absolutely no experience in technology, and those who do are all considered equal, single-tiered so to speak. Thus, the most experienced people are not consulted for design and architecture strategies, and the management feels a need to decide these sort of things as an act of leadership.
The result is that the programmers have to be the creative ones, because the "designs" created by the inexperienced management are incomplete and in many cases useless.
For the last couple of years, I've been using bits and pieces of my 'copious free time' to research and develop a hypothesis of what I might call 'rhetorical computing,' that treats human-computer interactions as speech (in the technical sense) or rhetorical acts. I've mostly gotten started with the endeavour because I am trying to learn how to program from a rhetoric/logic paradigm instead of a mathematical one. So far, it's going along as well as could be expected. I'm getting exactly the results I figure I should, comparative to the amount of time I'm able to devote to it.
In the meantime, I've been looking for scholars or practitioners who are working on similar things so I can possibly work with them, or, at least cite their papers and do the required field reading. I've already written to him. We'll see what happens.
I do think there is room in the field for different kinds of approaches (all of yours too), and I'd like to at least be permitted (somehow) to follow this line of inquiry until I know it won't work, or until I know it will. That's why I see an opportunity here, and not just an(other) argument.
I'm not a geek, I'm just a clever script.
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.
This is the biggest, yet most common, misconception in the software world, mostly espoused by the idiot managers themselves.
Sure it could work like that in THEORY, were a visionary architect foresees all the real issues, but down here in the trenches, never once have I seen that happen for anything but the simplest tasks.
In reality the customer doesnt know what the want, the manager is a clueless suit who pumps out buzzwords, and the analysts do essentially nothing. And the lowly "plumbers" are left to figure out:
The coders almost invariably shoulder the burden for all their "management" types, who, even if the are ex-programmers themselves, are flat out incapable of understanding the problems at hand.
The reality of the situation is, the coders are doing creative work, and they are typically the only ones who even have the ability to design solutions.
When the a Roman bridge collapsed, the engineer in charge was put to death. How much better would Windows be if we shot a programmer for every BSOD?
It may be new to you with a fancy nice GUI.. but someone has probably programmed you code already (except for game artwork maybe). A bit is a bit is a bit. I have actually been getting burned out, because nearly anything "new" I would like to do has already been done... check out sourceforge. BUT on the other hand one of the beautiful things about Open Source is you can help build the project you are already interested in and make it better than if you have a non-pro go alone ;)
The internet itself and the world wide web is a technology that has been in POS terminals for 40 years! .NET ---> same ole rehash -- Web Services ---L> someone say CGI?
They all just look prettier nowdays.
comon....
Programs write poetry about YOU.
Hades, PoD: Official Advocate
The big difference.
:).
;).
The problem is, in the IT world, the blueprint typically flies already
So, many many people make a mistake of launching the blueprint and calling it version 1.0.
Then they launch the "plastic/clay model" as version 2.0.
Then they finally launch the "working prototype", and call it version 3.
After fixing major bugs, they launch the real thing, version 3.1.
Funnily in IT, many customers don't seem to mind paying lots of money to fly the blueprint
Programming is art about as much as my turds are sculpture. One does not express one's emotions (except maybe greed or obsequiousness) through code. Therefore, it cannot possibly be art.
It's also not engineering. Bridges do something that directly improves the world. Most programming just exists in order to funnel money from one corporation to another. You can do that with checks or briefcases full of cash, though that would require that people actually leave the office and workers cannot be treated as humans that need the contact of anything other than a CRT and CPU and kb/mouse, since they are weak-minded and would thusly cause the stock price to drop.
I'm a programmer. I accept that my job isn't like anything else and is fundamentally useless and in fact detrimental to society. Why can't all of you? Human society ran for at least 5,000 years before the invention of the computer. These damn things are ruining our lives.
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...
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...
To put a witty saying into 120 characters, jst rmv ll th vwls.
from my university's Comp Sci for Poets, but noooo...... only stuff about mouses and squeakers and all that high falutin' "oh look at me, i'm smart!" jazz. Not a singled blessed poem the entire time. What a rip off
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.
Regarding OO and resue. Most "in the know" practitioners *don't* seem to rank "reuse" as the most important aspect of OO. Here is some comments about it:
http://c2.com/cgi/wiki?ReuseHasFailed
And here are some of my comments and observations about OO and reuse:
http://www.geocities.com/tablizer/reustalk.htm
One problem I have seen trying to make "generic software tools" is that to make them truely generic it seems one has keep adding features and bloating up the interface to cover all possible wants of each client (user). After a while it becomes almost easier to build you own from scratch or copy some base code and modif it than to navigate and use the complex interface. Copy-and-modify seems less full of worms than reference-based reuse.
IOW, copy-reuse works, reference-reuse does not, at least not for business logic. However, software engineering "rules" seems to prefer reference-reuse. Duplication is generally considered "bad". Understandable, but in practice it is not easy at all.
As far as what the benefits of OO are supposed to be, I get different answers from different OO fans, many of them vague IMO. I give up. I don't know what the benefits of OO are supposed to be. The top candidates seem to be either that it reduces the impact to the code of changes in requirements, or improves the human grokkability of the result. I have not seen any good code evidence of the first and the second is subjective because different people grok differently.
This whole OO thing puzzles me to no end. I don't get it. The shape, animal, and device driver book examples don't extrapolate to custom biz apps. I am either busted upstairs, or OO fans are mistaking subjectivity for objective benefits. I don't really question that it may fit thier head better, but I don't own their head.
Table-ized A.I.
I thought it's called CPAN?
:).
;)
I dunno about the rest of you, but that's why I like Perl. It's practical. I know I suck, so I use as much prefab as possible.
You geniuses can build your perfect shiny crystalline software atom by atom. If you have free time, and are feeling generous, make some prefab for us please
As for those of you who suck but don't know it. You still don't know you suck eh?
I studied poetry academically before I worked in programming (I started programming for fun around the same time I started reading poetry for fun - at about age 8). The practice of writing code and the practice of writing poetry are very similar in my mind; I don't mean that they're objectively similar, although there are objective similarities, but that subjectively the way it feels to be doing one is very like the way it feels to be doing the other.
That's not to say I don't suck at both, of course.
Anyway, here's a poem I wrote as part of a sequence called "Domain Names", which is a response to a question asked by the British poet Geoffrey Hill: What does the computer know of original sin?
***
Corrupted bug report received in error:
could not resolve address. This traces back
unendingly, is lost at last amid
a blitz of registers - beyond my skill
if not all skill. Go high-level to bare metal
in winding descent; resist light, heat and shards;
get zapped in nether regions. Every black
box has another black box inside it somewhere.
The shortest path is a relaxed approach
to the infinite: so route around bad sectors,
solicit patches, number each release
in cautious increments. Surely that kingdom
looms aloft where art is catalogued,
all things considered harmless. There the blinding
magii parley, indolent in their robes;
their elan earthed, exposed as commonplace.
Experience is a hard school, but fools will learn no other.
public static int poem(){
while(roses=="red" && violets=="blue"){
iLoveYou=true;
}
return(1);
}
mismanage, misappropriate, promote from without, promote for political gain instead of proficiency, refuse to QA, ignore results, set a separate set of criteria (one for employees you don't want to succeed and another for politically placed employees that can not make it on their own merits)
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.
>Especially when it comes to languages like C++.
When you build 'bridge-like' apps you just don't use C(++)!
Examples
is not a safe language.
Two reasons that software is not of the level of quality that people seem for some reason to expect (that of bridges obviously).
1. Supposed Coders/Poets are also expected to be testers.
I don't see why this is expected. You don't get the guy from Porsche/Ferrari who draws the design of how the car is supposed to look to actually build it down to the last nut and test every element of it.
In my experience, coders and testers have a vastly different view of the world and the one cannot do the others job anywhere near as well.
No coder should be without a tester - then at least the software I produced would be a lot better (proved to me on 2 projects done with a dedicated tester).
2. Where is the comeback when someone writes some useless code? No comeback to either the company or the individuals.
Try building a bridge and putting a disclaimer on it so that if it falls down killing everyone currently on it there's no comeback. Can't see too many people buying one off you or even walking over it.
As far as I can see, the quality software is the stuff that absolutely must work or it waste X billions or will cause major issues if found out - e.g. fly by wire, missile guidance, space programs, operating systems (can't sell hardware without it so no cash in door).
That, and the stuff that people do for love - Quake, OpenSource.
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.
...richie - It is a good day to code.
Go ahead and try to explain Quantum Electro Dynamics to a small child. It is after all the work that Feynman got the Nobel for. Should be easy.
By the by, Feynman himself only taught Beginning Physics post-Nobel for 1 year. It was an experiment. While it is great (it formed the basis for Six Easy Pieces and Six Not So Easy Pieces), Feynman himself found it to be a bit of a failure.
Any in-depth, high-level concept is hard to communicate. It is even harder if you are not using terms the other person doesn't understand. Don't kid yourself.
That was nice.
Great, then I can flip burgers too!
Engineering is the art of compromise.
Bridges have functional purposes, and some bridges are boring bridges that get you from point A to point B (or side A to side B, as the case may be). But many bridges also have an aesthetic (artistic) aspect, and I think that's what's being referred to.
Personally, I think it's the same with code. Given the same specs, anyone can write functional programs that do the same thing, but when you get down and look at the source, some will have a sense of beauty that go beyond pure functionality. Or it's like that warm fuzzy feeling you get when you see a really cool algorithm, solution, or design.
Or am I the only person who gets warm fuzzy feelings from code?
---
Open Source Shirts
Sure, I'd agree, if that was what the point was in the first place. This wasn't about fundamentally difficult concepts, though, this was about uncommented code with variables named 'n' and 'i'.
> 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.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I think you're way off base and misinformed if you
really think these ideas like using Ada and QNX
would have any improvement in software reliability.
Java? be real!
machine checked proofs for correctness?? hmm.. who
will write and check that program?
computers aren't magical and there is no such software out there
as far as the automobile comparison, bah. maybe
we should have an airbag installed in the LCD panel?
bah! it's all just buzzwords and java
Come on now, Windows 95 was perfectly acceptable at what it did. It managed to achieve backwards compatibility with a very, very defunct OS while incorporating parts of modern OSs. Hell, it managed to mix these two (conflicting) design goals and accomplish resounding commercial success, so IMO it really shouldn't be looked down on too much.
Hmm... I think when Richard Gabriel says this:
"It always comes back to creativity for me. Creativity thrives through diversity. So, if you look at creativity at large, lots of poets, painters, playwrights, fiction writers, and so on feed off of each other's creativity, but selectively. It's like biology, with its great diversity, where what really works well in particular environments is selected for survival. "
specifically "It's like bilogy".
I wonder how well his ideals will translate to bioinformatics, where you're dealing with organisims programmatically. Pattern matching is a LOT like poetry. I'd bet Richard Gabriel would really dig Perl, however, he probably at least appreciates the RegExp in Java (since I suspect he probably doesn't do much outside of Java, considering he works for Sun).
Very cool stuff... I only wish this MSA would take off a lot sooner.
...Ph.D. in Computer Science has YOU!
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.
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.
Would you characterise XP as being against the idea of reuse, at least reference-based reuse?
I think biz logic reference-based reuse works okay at a smaller scale, such as per module or per app, but not on an inter-app or inter-company basis.
Table-ized A.I.
where's the code?
I'd really like to see some poems, in order to bracket the criticism that I see there.
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 don't know about Dali in particular (do you have a link to that painting, BTW?), but many artists don't get famous/recognized until *after* they die. They are often characterized as ametures or bad artists by the critics of the day.
Also, those $5 Sears Painters may be "real" artists on the side, they just do the mass production gig to feed their kids until they are "discovered".
Table-ized A.I.
"Haiku is for batch files."
.
;)
Hehehe...
for each file in
do sed s slash leaf slash tree
on every line found; done
Okay, so that's a shell script... but it was just as fun to write.
Simpli - Your source for San Jose dedicated servers and colocation!
huh? when did e e cummings become a girl?
...many artists don't get famous/recognized until *after* they die. They are often characterized as ametures or bad artists by the critics of the day.
:-). But you're right, times do change. It used to be that all programmers were nerdy guys without girlfriends. Now it's common for a programmer to be cool and socially (and financially!) well off (although we still have our fair share of nerds, such as myself).
:-)
I think we'll see the same with computer technologies when old technologies start to resurface and we can fully understand their capabilities. If I knew which ones, I wouldn't tell you, I'd go and buy the patent on them
do you have a link to that painting, BTW?
Look for "Paranoia (Surrealist Figures), 1944" on this page. It's not his most complicated painting but it is interesting to look at. Lower on that page is his painting "My Wife, 1945", which gives you an idea of how his mind would dart from one thought to another, mixing everything in his imagination.
If you really want to see how well he could mesh imagery, check out his Metamorphosis of Narcissus. It's my favorite Dali painting.
those $5 Sears Painters may be "real" artists on the side
Hey, Sears paintings kick my paintings' ass any day
$8.95/mo web hosting
Doh, I thought MSFT has released 1999 different version of windows before Win2k!
Try explaining almost anything to a four-year old:
"Why is the sky blue daddy?"
"Well, honey, the water particles in the air have chemical characteristics such that they absorb... heck, blue just turned out to be the best color for it. Don't you think?"
"I like blue."
Customer: I need to cross that river.
Contractor: OK, let me study your needs, I will come back with a proposal.
some time pass
Contractor: Here it is... you need a bridge.
Customer: Oh! Fine. Can you begin constructing it now? I want it for tomorrow 9 o'clock. Here is $500.
Contractor: It is impossible! I can't built a bridge for tomorrow! And for $500 dollars!
Customer: How come, it is just a bridge! There are plenty of bridges - I looked on the Internet! Here is $100 more. And your competition said he can!
Contractor: My competition said he can??? I'll se what I can do.
some time pass
Contractor: Here it is! (showing a fragiler bridge made of ropes)
Customer: Nice color. Can I cross it with my car?
Contractor: Of course not!
Customer: Then it is useless for me! I need to be able to cross it with my car!
Contractor: This was not in the specs you gave us (with a wide small)
Customer: OK then, can I cross the Atlantic with it?
Contractor: You want to cross the Atlantic with a rope bridge?
Customer: Do you mean your solution is not scaleable?
and so it goes, and so it goes...
The important point to me was about training methods. The training and study methods used in the arts could be a useful addition to the art and/or science of programming.
I have close friends in medicine. In their training, they are organized into teams based on a specialty, or subspecialty -- pediatrics, ob/gyn, surgery, etc. As a 3rd or 4th year med student, they are at the bottom of the line, under a first year resident, who in turn is under a few more advanced residents, who are lead by the chief resident. At the top, is the attending physician. At first this struck me as an overly rigid almost military style hierarchy, or something archaic like a guild or apprenticeship system. But, one benefit is copious amounts of mentoring along their progression through the hierarchy. This is great for transferring the hands-on practical knowledge and skills that are a necessary companion to theory.
If you ask me, critical review of your own code with the aid of a talented and experienced developer, or critical review of code written by talented developers is entirely too rare, and most of us would benefit greatly. This kind of thing facilitates the transfer of good ideas and creative energy.
-cbare
Ok... How much do you know about rhetoric?
:)
Anyway, what I mean by a "rhetorical paradigm" in terms of programming and programming pedagogy is to attempt to learn and use programming as a speech act, or a linguistic construction, rather than (strictly) as a mathematical or logical algorithm. I'm trying to "code-switch" (if that isn't a horrible pun) concepts in programming to their linguistic and rhetorical analogues (examples -- mind...blanking...), like "grammar," "syntax," "graphemes," "propositions," "declarations," "case," "metaphor," etc., as a means of providing an alternate viewpoint, sort of like the people who approach higher physics through philosophy, if you catch my drift.
My simplified and slightly different test case (not precisely programming, but a parallel, easier, but similar programme) was to teach myself how to use Unix-like command line syntax to perform various functions inside Linux, while treating the OS as a "language" spoken between the computer and the user. I haven't gone too far with programming itself yet, but that's mostly due to a lack of time and appropriate teaching materials.
If you're interested further, please e-mail me at scripsit@starmail.com, and I'll send you a list of my reading and research materials so far.
I'm not a geek, I'm just a clever script.
Some of the posts mention that there are a few geniuses of programming and many many plodders, and you can't train the plodders. The geniuses will produce art, the plodders bricks. In my experience, those who pick up on grammar quickly can express themselves more readily in any language, whether artificial or natural. Poetry or code, both do something with words as opposed to merely describing reality, as simple statements do. (This is a branch of philosophy called Speech Acts.) If you can discern the parts of speech intuitively, you can make more interesting and meaningful expressions, because you have more mastery over the parts. Likewise if you have an innate understanding of logic and variables you will likely write code more efficiently as it's less likely to be buggy. Can this intuition and innate understanding be taught? I don't know the answer to this question, but you can teach techniques that encourage exploration of connection. Pythagorus linked astronomy and music and math. Diagramming sentences helps you see that there really is reason to rhyme.
Fuck You!
Just because people whose job is not critical can afford to "try something out" does not mean that REAL programs are not engineered - in the truest sense of the word.
I've worked on code that controls nuclear plants. Believe me, it was engineered. It was simulated. It was revised in design and implementation countless times. It doesn't crash, it doesn't fail, it works better than most people's nervous system.
Just because your idea of programming entails crap such as shell scripts and "quick and dirty" hacks, does not mean that programmers, REAL programmers, are not engineers, architects, and artists of the most discriminating caliber.
Perl is a Swiss Army Knife. Slashdot, as a site, is at best, a covered bridge from Madison County. It is not a skyscraper. The people who write what you seem to consider "programs" are nothing more than white collar drones with workbenches in their garage and some power tools from Sears. Yes, any bank teller can go and build a deck in their back yard. This does not make them Professionals. Similarly, anyone with the most basal understanding of a language can put hammer to nail, and bang together a "program". This does not make them a professional Programmer.
REAL programs run space ships (except those that crash. Those are written by people who carve Indian heads out of stumps with chainsaws), power plants, pacemakers and banks. REAL software, designed and engineered, instead of hacked together between meetings, is as intricate as any tangible piece of engineering. And, as it comes after 50 years, instead of 50 centuries, of practice, I think we're doing pretty damn well.
The popular opinion of programming, the "shoot from the hip" attitude you claim as prevalent, is a problem. People think we all ride Razor scooters in our offices for God's sake. You and I clearly know better, but the word just isn't getting out.
Every time some putrid pundit whines about "the IT shortage", I want to scream. There is also a shortage of qualified rocket scientists, and metallurgists - the bolts and rivets on the space shuttle are made by grunts who push buttons on a robot, after all. But the few qualified people that are there, put us on the Moon.
There isn't a shortage of talent. It's just misplaced. It's thwarted by the weekend carpenters, who once read a "Learn C++ in 21 Days" book, and not command real salaries because they claim to be Programmers.
There is REAL talent out there, and it usually works for ignorant fucks who choose bravado over skill and common sense. This is why so much retail software crashes at the drop of a hat. This is also why I think we need a "Professional Software Engineer" certification - just as we already have a "Professional Engineer" one. You can do engineering without it, but your work better be signed off on by one before it sees the light of day, and puts the public safety at risk.
That is all.
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
Programming is more like construction. Bridge building is a specific problem to solve, like sorting. Just like there are different bridge styles (suspension, cantelever, etc.), there are different algorithms for sorting (quick, bubble, etc.) And, just like there is different data to be sorted of varying amounts, bridges are built in different environments and different lengths.
It also makes a difference if we are talking about large, production, highway bridges built by professionals, or plank-over-the-creek bridges built by the neighborhood kids.
I can say that I agree. The big thing to understand is that writing is writing is writing. Whether you're writing essays, poems, music, code, recipes, fiction -- it's all vaguely the same process: put down the marks on the page (screen). Get up from your chair, go to the water cooler, think about it some more. Get inspired and rearrange the symbols in a new and better way. When you're finished some entity comes along and reads what you have written, maybe acting on it or just imagining what you've depicted. Whether the thing that reads what you've written is a computer or a person doesn't make a whole lot of difference.
:-)
Nowadays I don't like people much so I am writing more for computers
I think the point the poet-programmer is trying to make is that though the set of words are finite, the reality the poet seeks to describe is infinite and ever changing. If code is another way of expressing something about the world we live in, then surely even a lowly, lonely programmer is a poet for there will ever be newer ways of putting words togather to create beuty.
life is all about searching and sorting
Any task well done pleases an specialist of the same field.
IANAL but write like a drunk one.
You struck upon one of my pet peeves.
(One I had long forgotten.)
Your sentence should read:
"six LINEAL feet",
not "linear".
I started off my career as a Software Engineer with degrees in both Computer Systems Engineering and Computer Science, but over the years I've feel the best software I develop is through an evolutionary process rather than a rigid design everything first based approach.
Too often after spending weeks nutting out a design document with UML, dozens of use-cases, once you start programming and running initial versions of the software, the design will quickly become invalid and the design will be refactored to work better.
The reason this invariable occurs is that software processes are inheriently complex systems. No matter how well thought out a design, it is impossible for anything but the most trivial of systems to envisage all possible states the program could end up in - this is because software processes are driven by dynamic input that is hard to predict. This is why the best understanding of how a program should work (and how it currently does not meet design requirements) is during the runtime execution of a program where it's dynamic behaviour can be examined.
This is why I feel the higher quality software I have developed is usually the result of software where I start out with a preliminary design - don't try to solve everything up front, just spend an hour or two outlining a high-level approach. I usually break the problem being solved down into a series of simplier problems - program to solve them, profile the dynamic behaviour of the program to see how well it solves the program, then go through an iterative process to improve and extend the program.
This is why writing good software is very different to designing a bridge. You can't iteratively design a bridge - it needs to be well thought out before you order the bill of materials and get a large workforce moving on it. However I feel that trying to fully work out a design of a software process before even trying out a simple version of it to see it's runtime behaviour can often be wasted. The design will rarely handle every possible dynamic situation the program can end up in. An iterative design-program-test process is the more efficient way of designing software.
Another tear-jerker of techno-serfs pretending that slaving in a keyboard is somehow artistic.
/.ers are the hope of a sane technological future I am betting in favour of Palladium, MS and the DMCA....
Most unpleasent.
When we program we invent something new every time!
I wish we had payed more attention to concepts like code reuse.
And then the cavaliers that say it is better to be high in drugs in opossition to apply sensible Engineering techniques to software design.
If
IANAL but write like a drunk one.
Sheesh.
You can argue about software process or design but that misses the point. Software that is well designed, bug free, and works well may not necissarily be beautiful. However, functionality and beauty do not have to be mutualy exclusive. There are few things, even bridges, that are both beautiful and functional. This also applies to software. Beautiful and functional software is not a necissary goal, but it is a worthy goal.
Not at all. XP is for re-use. But in XP you discover reuse through refactoring. So, in XP you don't develop the "general problem solver", rather you write code to solve your current problem.
When you get to the next problem and you see similarities, you factor the common code out.
So with XP you not only get re-usable pieces, but you get pieces that are actually re-used.
...richie - It is a good day to code.
We've only been building aircraft for 100, years, spacecraft for about 50. If they had software's abysmal record, noone would ever fly...
Acronymfinder gave the following definition for AARP: Appletalk Address Resolution Protocol
I didn't realize famous actors cared about appletalk! They must be the only ones.
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, 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).
The beauty of recursion is something as natural and poetic as music to me.
Actually I just finished a grad-level course in Denotational Semantics of Programming Languages, and if there's one thing I learned, it's that:
It's shocking how much complexity recursion adds to the mathematical description of a programming language. When I first learned functional programming I thought "this is so beautiful, it's just like mathematics". Well yeah, except that mathematical functions don't have to do anything! Recursion is such a pain in the ass, I think I'm going to avoid writing programs that use it on esthetic grounds.
Mind you, the only thing uglier (much uglier) than recursion is local variables...and I think I have to choose one. :)
I believe the true link between Computer Science and English Literature / Creative Writing is that both are lacking in academic merit.
CS, at least the way it's taught around here, is basically the bastard child of Mathematics and Engineering -- lacking the rigour of either. It's mostly populated by students who either didn't get the memo that Commerce makes more $ or don't have the necessary social skills. And the rest of the students went into it because they want to make video games or they decided that it was time to stop using their 1337 5k1llz for evil.
From the opposite side of the coin, English has evolved into much more meaningful disciplines like Cultural Studies without completely killing off the original species. So now students who aren't actually interested in the societal questioning of the real liberal arts can get a degree for reading lots of books. Or if you think you're a good writer but realise that you'll never be good enough to do it in the wild, you can get a degree in creative writing. Never mind that almost none of the successful writers working today wasted their time with such a hypocratic undertaking.
Both degrees are for people who don't like reality but want to pretend they can be successful. Both are for people who can't produce work that normal people can understand. Both practices consist of little more than mental masturbation.
[laughing] And just think of the consequences if your syntax is faulty: "You've got an extra syllable in line two, so don't be surprised when it deletes all your files!" or "There's no mention of nature -- so of *course* it got stuck in a loop!"
Of course, that's nothing compared to what happens when you omit a semicolon in your epic source.. the hapless actor performing it won't know where to stop, and may well fall off the platform and break something!
~REZ~ #43301. Who'd fake being me anyway?
I find this kind of insulting. Bridges and software are equally difficult to design, just in completely different ways.
;-)
Try writing a program using ONLY the objects and calls given by Microsoft/Apple/whoever and not creating any of your own objects, functions, or GUI widgets. Have fun writing anything more complex than a non-GUI calculator.
Likewise, try building a bridge where instead of the limited set of member shape/sizes we currently have, you have an infinite number to select from, and your boss expects you to use the least amount of steel possible to save $$$. You'd be designing forever.
At my school, Electrical/Computer engineering is the hardest engineering major to get into, while civil engineering is the easiest. The programmers think that this is because they're so much smarter, when in reality its only because the job market wants programmers right now and pays more than civil engineering does. I've put assignments in front of programmers who think they're god's gift to MENSA and seen them be stumped by STATICS (i.e. high school physics problems, F_net = 0).
Bridges are just as unique as software programs. Every one must be uniquely designed for a loading pattern, soil profile, aesthetic requirements (something I almost NEVER see programs designed for), material limits (can't always use just anything), political maneuvering, earthquake probability, wind strength, and even geology.
Civil Engineers Sound Off Like You've Got a Pair! Don't take this garbage from programmers. We may make less money, but we're far more attractive and don't smell nearly as foul. Not to mention more modest
"We've only been building software for 50 years, and almost every time we're creating something new."
I would like to see a list of people here who have ever created anything new with software (and what they did.) A program, an algorithm, a formula, a design pattern, ANYTHING.
Thank you very much.
It's only been in the last 50 years or so that bridge building innovations have slowed down. It only took 30 years or so for software to level off.
I agree that peer "Code Review" is a very important process. We've implemented a code review where I work, and it has been very successful. In fact, I'd recommend using a similar process to developers in almost any situation.
Attendance to our code review is not mandatory (unless you are submitting code), but we really encourage any developer who isn't in "crunch time" on their particular project to attend. Our code review really incorporates all these ideas:
1) Peer review of code going into the testing environment.
2) "Idiot check" testing by peer developers to try and break the code while still in the development environment.
3) A place to showcase new, cool code - code that accomplishes a new goal, or accomplishes an old goal in a significantly better way.
4) A place to describe new processes and/or methodologies that are being put into place for development. (For instance, one of the first things I did when I arrived was spearhead the use of source control software through this process.)
5) A place to fawn over and discuss the latest software and hardware gagets. (mimio started showing up everywhere after one of these)
The only thing that does not go into code review that makes it into the testing environment is "copy n' paste" code - code that is almost identical to another piece that has already been written. (A lot of our ASP pages are like that - call some stored procs, has a form, dropdowns)
I can honestly say that code review has made me a better programmer. First of all, it puts extra sets of eyes on your code - and that makes a difference - I guaruntee people will spot things you did wrong. Secondly, it gives me a chance to see other code that is new and well written. Then I can incorporate those ideas later on in my own code.
Furthermore, it prevents inferior code from going into the user acceptance testing environment and, consequently, the production environment. Every company has a few developers who write second rate or below standard code, and this weeds that code out before it can get in and screw up or slow down the system.
Now, obviously, every developer does not have time to step through the logic on every piece of code that comes through. Thats not really the idea though - thats the developers job. Mostly readability, the use of standard naming conventions, and obvious problems are the sort of thing that is looked for. "Can I debug and/or modify this code if I need to without your help?" is a question I ask myself when reviewing. Generally, the only stuff looked at in heavy detail are pieces that are experimental, bottlenecks, or intricate.
It only takes up about 2 hours of my week, and it makes all the code that goes into our system significantly better, as well as improving our programming skills. All in all, I'd say its a very worthwhile use of our time.
// harborpirate
// Slashbots off the starboard bow!
You can do machine verification for Pascal, Modula, and Java, and even some machine languages, but C and C++ are just too ambiguous to formalize. When C took over, the formalists just threw up their hands and gave up.
what on earth does the S in RTFS on one of the thongs mean, read the fecking snatch?
The difference is not so much in how familiar we are with constructing bridges as in the fact that constructing a bridge is dealing largely with matter. While dealing with matter involves many challenges, far more of the parameters are relatively fixed - mass, tensile strength, density are all within well-understood boundaries.
Compare this with software. Often, the basics from which we construct software, as well is it's boundaries and requirements, are nowhere near as well understood. Often, they consist of other abstract constructs - business rules, corporate policies, usability guidelines. They might be instantiated in some way - test cases, software components, interfaces to other systems. In some cases - e.g. embedded software - the boundaries are with tangible objects.
One could thus suggest that the design of a bridge and the design of software share many attributes - they are both largely involved with abstract concepts. Bridge designers work with numbers and formulae representing the real world properties of their materials, requirements etc. Software designers deal with abstract representations of the real world for which their software is intended.
However, there are also many differences.
Bridge designers have usually got a larger body of previous work from which to re-use solutions. While the Patterns movement is making headway, and there is an increasing body of informal knowledge, we developers still have to re-invent a lot of wheels; for many domains, there's often simply no published information available.
Everybody knows what to expect from the bridge, and the outcome of building the bridge is usually pretty unambiguous. It's rare for the people paying for bridges to disagree about it's purpose, and I know of no occasions when the marketing director decides - halfway through construction - that the bridge needs to cater for trains as well as cars.
The intangible nature of software means that it's hard to explain what the software "does" until it's finished. This in turn frequently leads to conflicts between stakeholders - "it's an order processing system !" - "no, it's a sales force automation tool" - "no, it's an interface to our accounting software". This is why most software methodologies contrate on either improving the quality of the specification and the way it is communicated (e.g. the Unified Rational Process), or on producing tangible results early in the process, and making it cheap to change (eXtreme Programming, for instance).
Once a bridge design is complete, the "construction" phase is typically conceptually straightforward - there are a lot of practical problems at a micro level, but the purpose of the design is to make sure that two teams starting at opposite sides of the river meet in an agreed place.
With software development, I have found that conceptual problems extend all the way from the high-level design to the detailed implementation. No matter how well-thought out your object model, there are always details which are conceptually hard to solve. It's not unheard of for 2 software components which were designed to be compatible to fight like cat and dog when introduced to each other in the wild...
I believe that trying to compare software development with other disciplines is futile. Software development is a unique discipline, with many disparate specialisations and a short history. It combines craftmanship with engineering disciplines, math with instinct, and no two projects are ever identical. That's why it's exciting (to me, at least), but that is also why it is such a difficult thing to do well.
It's all very well in practice, but it will never work in theory.
Well, I'm working on a project to teach computer programming as if it were a foreign language. It seems that grepping a computer program as one were applying a certain set of grammar rules in a written language, is in fact more efficient for those "verbally oriented". The corollary to this is that teaching computer programming as a branch of mathematics is best for the mathematically oriented.
I think that software development is unlike civil engineering, and attempts to draw a parallel often lead to false conclusions; a few inches below pointy hair is the main danger zone.
The fundamental difference is that physical, tangible products like bridges have form and substance. Software (or a song, or a novel for that matter) is pure form. Substance is a lot more difficult to change - there's a raw material cost, and it's subject to the laws of physics. Form isn't. That doesn't mean changing it's free, but it will usually be cheaper. Those pesky laws of physics are why you can't build a bridge anyware near as badly as you can create software; it would fall down before it was completed. We've all criticised code only to be told, in a whiny voice "well, it works"[1]. No laws of physics to bring it crashing down - just a different screen resolution, an address with an alphanumeric post code, introduction of the Euro, an invoice with 'too many' items...
Ever fought your boss to rewrite something, when he thinks it would be better (i.e. quicker/cheaper) to modify the existing one? He's subconciously thinking about reusing the bricks from a knocked-through wall to build a patio. But there's no raw materials in a program. If you're thinking "But surely code is reusable?", you're right - but only if it's written the right way. You can recycle the form, but only if it's good form. OO is neither a sufficient nor a necessary condition for this.
Moving on to the poetic side of things, I often find that if I get the concept right, the code almost writes itself. I have written programs that should have taken a week in one day - but only by spending the first four days thinking about it. I've even been criticised for "not typing fast enough", and for not writing "very many programs" and that they were "surprisingly short" - even though they had better functionality that the crawling horror they replaced. I've also had to modify code where the programmer clearly didn't get the concept right; I think we all recognise that when we see it.
As to the bureaucracy side of things - I couldn't agree more. Partly the reason is as suggested - it means manglement can pretend it's in control - but I think a lot of it's driven by the misplaced analogy above. Moving or resizing a door is expensive, so it needs to be right to start with. Moving a GUI component isn't. In the former case, the overhead pays for itself, in the latter it doesn't. As to standards, I've never come across any that 1) when obeyed will always produce good code 2) when disobeyed will always produce bad code (my own personal ones excepted, of course). [1] Better than "well, it compiles", I suppose. Just.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
...I think I'm Dr. Seuss.
That guy is cool. I like that idea poetry and code, code as art.
Being a lowly self-taught programmer I have learned to code by instinct and intuition. I have written programs purely in hexadecimal on an x86 just for fun to see if I could do it. Mostly I stick with C and Assembler. I also love Python and find a use for that as well.
Artists use mathematics too. Perspective, for instance. Look at Da Vinci's work. Lots and lots of mathematics in there. Was he an engineer or an artist? I say he was a true artist. Much of the stuff you do as a graphics programmer is also taught in Art schools but with a different perspective on it's application. Today with computer art it's all the same thing really. Instead of learning the Phong algorithm you learn to apply phong shading to your output. Etc etc.
I think they should do away with Computer Science and just merge it all into Computer Engineering. Engineering in my opinion is an art. You are highly trained in math and science to create solutions to problems. Same thing with programming. You draw on science and mathematics but the end result is a piece of art, a listing of machine instructions that perform operations. The arrangement of the instructions are like atoms in a molecule. Arrange them one way you get a stable atom. Another way you get an ionized atom. Just a stupid analogy not meant to be a nobel prize winning speech mind you.
Yeah, bad programming is always identifiable: the fargin thing doesn't work, crashes, or gives the wrong result.
You can not tell me you can look at highly optimized assembler code and instantly say 'oh this is bad code' or 'oh this is good code' you have to study it inside out and count it against what is true about the underlying machine architecture. And of course it has to work correctly. 'Good' code is both optimal and works correctly. But that is to the machine. It is bad if you can't friggin read it or follow it in any way (no comments or anything).
In the end though a program is only bad when it fails to work or do what it was created to do. If it solves the damn problem but is written like crap it still works and therefore it can't be a *bad* program, just a really crappy written/slow program.
The same thing with a bridge. A bad bridge is one that falls apart like that one they built and it shook up from harmonic vibrations ( I dunno what I saw it on discovery). It was beautifal design and wonderful except it failed to take into account the vibrations of the wind that caused it to oscillate out of control and fall apart.
'BAD' is really a matter of personal taste in art. I consider bad code any code that is really sloppily written and hard to read/follow. Yeah I think Quake 2 is BAD code but a GOOD game! Don't care if it's good and works right if it has absolutely no comments and very poor structure it's bad. And then I think much music and art and literature is bad because of this or that. No doubt you'll think the music I like (heavy metal) is 'bad' and 'evil' and 'satan' but I think it's funny as hell and it cracks me up.
Ok so from one aspect we can say good code must work correctly and run optimally on the machine. A matter of knowledge and engineering, not really artform. Thus programming is fairly mechanical, hence why compilers work. Except compilers never generate truly optimal code but must brute force alot of things because they can not understand concepts not programmed in them.
But from algorithm perspective, it is more an artform of combining math and science togethor to derive a solution to problem. Further artform is to code it optimally for the target machine. Most compilers can not produce perfect machine code but a good programmer can and it is more of an artform and experimentation than a cookbook I know i have done it for along time and there are no magic books to help you write perfect code in machine language for say a pentium.
Design is a true artform. Hacking out code for the designer is just mechanical. Not really much creativity in being a grunt coder. You just take the design and whatever part given to you and code it. As long as it works in requirements you did your job.
But all work done by theoreticians in my mind is artwork. I think even programming is artwork in the sense of poetry. Now I am losing you but, every letter you type, each whitespace, your comments, everything that way is an artform to me. That is the poetry to me hehe. Not really the final machine code instructions although I like to think computers are poetic too in a monotonous way.
Depends on how you look at things but I consider programming to be more of an artform than a science. Despite all the crap I ranted about, programming almost always comes down in the end into knowing nuances of your API and OS and knowing how to balance all this stuff togethor to work correctly. Even though manual says it works this way it never really does in reality. My experience with Windows and APIs and software is there are always funny exceptions you figure out by analyzing and testing to find solution to. Not in school! You do it by performing and practicing like a musician does with a guitar. Hence it is an artform not a science. And art relies heavily on science too, but it is not science. Yes it does go take some art classes it touches on all the same topics in science except with a different perspective on things.
Blah!