Hacker News Reader

Comment by vbtemp | Hacker News Reader

Oh come on. Programming is not writing. When you're reading a novel you don't have to worry about concurrent access to a resource, threads, asynchronous events, or even much less conditional branching. With all due respect, I think this is just an inane post. That said, I can't blame the guy for dropping software development and moving to Japan to teach ESL. I often entertain similar fantasies all the time - programming is a great way to have the zest for life sucked straight out of you

Edit: Would someone have the courtesy to mention why they are downvoting?

View on HN

And in programming you don't have to worry about capturing the audience, the development of the characters, the story arch, being clear but not being obvious, etc.

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.

They're not nearly the same thing. The scope of modern literature has hardly moved in hundreds of years. Compare Updike, Roth, or Mitchell to Dante or Shakespeare -- they'd seem like near contemporaries in programming.

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.

They have one more thing in common; the text is read by other people. And the better written, the more effortless it is to understand.

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.

Unfortunately, this metaphor breaks at the onset. Programs aren't primarily written to be read by people. They're primarily meant to enable functionality. Readability of code is important, but not the ultimate ends -- it is part of the means.

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

The author argues that good code should be written for people. The metaphor doesn't break just because you disagree with the author's point.

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.

The author argues that good code should be written for people.

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.

The author never claimed the code should be written only for people, then it wouldn't work, would it? You're either trolling or mistaking the rest of us for complete morons.

My current theory is that programming is quite literally writing.

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.

This is called taking an analogy too literally.

I'd say its called creating an analogy where one shouldn't. As a general rule, and maybe I'm too influenced by Dijkstra -- don't introduce metaphors/analogies where you can reasonably talk w/o one. In this case, no clarity was introduced by its addition.

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?

I saw what you did there ;-)

You're looking at a pretty mature art form, although "hardly moved" seems inappropriate for a time period that includes the rise of the novel.

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 reading a novel you don't have to worry about concurrent access to a resource, threads, asynchronous events, or even much less conditional branching.

When you're writing a novel, you do.

I would like to add this that when you are actually doing the non-lazy work of interpreting a novel, you do as well.

Never read Chronicle of a Death Foretold?

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.

> programming is a great way to have the zest for life sucked straight out of you

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.

Point taken. I wish I were you!

I don't mean to be overly harsh - I understand how it can be tough + draining sometimes.

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.

:-)

When I'm programming, I like to call race conditions "dramatic irony."

> programming is a great way to have the zest for life sucked straight out of you

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.

Reply on news.ycombinator.com