Both in programming and writing, the actual writing part is the easiest part. And while bad programmers can make a program work, and bad writers can tell a story, it takes good ones to do it coherently, efficiently and enjoyably.

It's not the exact same thing, which I don't think anyone is saying, but there are some similarities there, especially the aspect of writing readable code.

In contrast, in the past, programs to do Newtons method or compute trig tables were often the full scope of a program. You certainly never had a Halo 3, Windows 7, Google Search, or WordLens application written even 50 years ago.

Good literature isn't about automating increasingly sophisticated processes. Programming is all about that. This leads to increasing complexity of programs, where the goal of software engineering is to abstract/hide as much of the complexity as possible.

The only things they really share in common is that they're both written in text. If programs were written by soldering wires no one would make such odd acquisitions (do EE relate circuit design to writing literature?).

I think we give this slashdot author far too much credit.

I think this aspect of it is what the slashdot author is mostly talking about, suggesting that if you write code as if you were writing to the next programmer, rather than to just the computer, your code will be better for it.

Clearly, programming and writing isn't the same thing. Nobody is claiming that and, guaranteed, nobody here thinks that. It's a metaphor and like any other metaphor it breaks if you bend it enough.

But the important part of my post was that programming is about automation. It's not about weaving a story, even for the next programmer. It's about building abstractions for automation. And yes, its important for other programmers to build on top or service it, but given a choice between the right user experience and dev experience, user experience should usually win (although there will be some exceptions).

IMHO, any dolt can produce code that only works. All too often I have to sift through horrible code that works, and I think the author is right in that if the programmer who wrote that (sometimes that's me, sometimes it's someone else) had had the next programmer in mind when he/she wrote it, it'd be much less of a pain.

If good code were written only for people there'd be no quicksort. No fast implementations of FFT. Probably no fast versions of memcpy. The reason is that coding is not primarily about writing for other people. Look at Donald Knuth's code. Extremely well-written, yet certainly doesn't stand on its own. And there are certainly design decisions that optimize for both asymptotic complexity and small constant factors.

My point is that analogizing this to books does no one any favors at all. We're having a conversation on the merits, w/o having to allude to neither haikus nor novels, nor gerands, nor foreshadowing.

Programming is difficult, even for code that "only works" (you'd be a billionaire if you could find a way to quickly produce code that "only works"). It has little more in common with writing than tarot cards -- which also are made to be read by humans.

That's what the author wrote.

Lets take another (stupid) quote from the author: Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel.

There's no absolute nature regarding the state of ability for any given task. There is no way to map fluency in English to fluency in any other domain. It just doesn't make sense.

This is just all around lazy thinking. It's buying into a metaphor because you either don't have the ability or desire to actual think about the real issues. edw earlier in this thread actually took a little time to think about the issue. This slashdotter made no effort, had no substance, no data, just a cheap metaphor that fell apart upon first glance.

or mistaking the rest of us for complete morons

How's this for lazy thinking -- I use duck typing.

It's like adding gravy to mashed potatoes. Sure it may make the potatoes taste better, but now you can't put the gravy back in the gravy bowl, can you?

You might better compare the films of 100 years ago to the films of today to see an increase in complexity similar to the march of programming progress.

When you're writing a novel, you do.

In programming, do you have to worry about phonology, slang, or number agreement?

The guy's deeper point is that programming is a language acquisition task and we would do well to take the rich set of lessons from ESL and foreign language learning and apply them to CS learning. Will all of it stick? No. But there is fertile green field to plow here.

Sounds like you're in the wrong field. Just because you find the thing a drudge doesn't mean others feel the same way, and personally I find the cynical 'well real-world programming is ultimately crap' specious and poisonous - to you it is, to me it is not. Why are you still doing it? And why are you stating it like it's some immutable fact we are all avoiding somehow?

Personally, I find programming a wonderful, amazing thing even when working on the most incredibly dreary software, and of course considerably more so when working on the more interesting stuff.

This kind of stuff is unfortunately common and applicable any + all professions + activities out there. If everybody listened to the nay-sayers, nobody would have tried doing anything.

tl; dr: haters gonna hate.

I'm also not acting under any illusions here - there are times when it's miserable, the key is whether the overall thing itself outweighs those moments.

Also be cautious as to whether burn out is involved... that shit is pernicious.

:-)

If that's what you really think then maybe you should go become an ESL teacher in Japan, or at least try a new position that may fit you better. I find good programming roles to be highly enjoyable, challenging, and rewarding jobs. Sounds like you might need a change - shake things up a bit, re-examine assumptions and that sort of thing. It's very bad in the long run to hate your job.